home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1048 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. Date: Tue, 26 Jul 94 20:57 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re: A better objc_edit()
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. What I'm asking is... how does an application put up a backdrop on the
  9. desktop, presumably by replacing the desktop form, and still have the
  10. desktop icons appear which were on a different form?
  11. ========================================================================
  12.  
  13. You can't.  Both sets of icons cannot appear at once.  The system will
  14. switch object trees for you.  If an icon stays in place, then it is an
  15. iconified window, which by convention is actually a very tiny window
  16. with no gadgets.  Those are not part of the normal desktop form.  
  17.  
  18. Actually, there IS a way to "add" icons to teh desktop form, but it
  19. will not "support" them, and assuming you don't crash something, they
  20. might display.  This can be done through the WF_NEWDESK call.  There is
  21. now a wind_get counterpart to wind_set as of AES 4.0.
  22.  
  23. ========================================================================
  24. handling clicks on the desktop.  The point was to simulate WF_BEVENT in
  25. normal TOS.  With normal TOS, if I click on a window, the window gets a
  26. WF_TOPPED message.  Since I want to avoid that, I have to handle mouse
  27. ========================================================================
  28.  
  29. No, you just convert the WF_TOPPED message to button clicks.  You 
  30. can't do drags and such under normal TOS from a background window, unless
  31. you use the right button.
  32.  
  33. ========================================================================
  34. You can't make a distinction with normal TOS.  You only get WF_TOPPED
  35. messages.  What I'm trying to do is simulate WF_BEVENT when I don't have
  36. a multitasking OS.
  37. ========================================================================
  38.  
  39. You can't.  You can't get the app_id of a window handle without a
  40. multitasking AES (maybe WINX might support it though).  This is one
  41. of the parts that make drag-n-drop impossible on an older machine,
  42. the second being pipes, which you really need MiNT for :-)
  43.  
  44. Also, I've seen a few posts about working around bugs in TOS 1.0.
  45. Please, we have to dump the old sooner or later.  It is the users
  46. responsibility to upgrade his OS on occasion.  ATARI says the minimal
  47. support should be TOS 1.4, not 1.0, and 400 line 80 column screens (by
  48. 400 lines I mean scan-lines not character lines!)  Really, TOS 1.4 and
  49. 2.06 have been out for awhile.  Get 'em.
  50.  
  51. Let's not fall into the DOS trap and support ancient operating enviroments
  52. forever!   The applications dictate when the user will upgrade.  The
  53. major flaw of the ST, and the reason why it has lasted so many years is
  54. that the developers write for the lowest common denominator.  Many don't
  55. even TRY to support better, let alone right out refuse to support an old
  56. and buggy OS.
  57.  
  58. I say we do just that.  If there is a problem that can be solved by upgrading
  59. to TOS 1.4, then do NOT fix it.  Either have the user get MultiTOS, buy
  60. new ROMs, or find an auto-folder patch.  Writing around the problem will
  61. make things worse in the long run.
  62.  
  63.